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REMARKS 

This responds to the Office Action mailed on January 13, 2009. 

Claims 1, 4-6, 13-14, 19-20, 55, 58-59, 65-66, 68-69, 73-75, 77, 80-81, 83, and 86-88 are 
amended, claims 2, 3, 21-54, and 56-57 are canceled, and no claims are added; as a result, claims 
1, 4-20, 55, and 58-88 are now pending in this application. 

§ 102 Rejection of the Claims 

Claims 1, 13, 19-20, 55, 65, 81 and 87-88 were rejected under 35 U.S.C. § 102(b) as 
being anticipated by Strassner et al. (U.S. Publication No. 2004/0230681). 

To anticipate a claim, the reference must teach every element of the claim. "A claim is 
anticipated only if each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference." 1 It is not enough, however, that the prior art 
reference discloses all the claimed elements in isolation. Rather, "[anticipation requires the 
presence in a single prior reference disclosure of each and every element of the claimed 
invention, arranged as in the claim." 2 Furthermore, "[T]he exclusion of a claimed element from 
a prior art reference is enough to negate anticipation by that reference." 3 

In the present case, Strassner describes an apparatus and a method for provisioning 
services that includes configuring one or more different devices. According to a specific 
embodiment, an apparatus for provisioning a service comprises an information model configured 
to represent a network resource of said network, to represent said service, and to represent the 
provisioning of said service, and a processor configured to use a subset of business rules and 
processes, which can be represented in the same information model, to constrain the 
implementation of said network resource. In accordance with another embodiment, an exemplary 
apparatus and method governs the manner in which a configuration of a network device is to be 
created, verified, approved, and deployed. 



1 Verdegaal Bros. v. Union Oil Co. of California, 814F.2d628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987) 

2 Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 730 F.2d 1452, 221 USPQ 481, 485 (Fed. 
Cir. 1984) (citing Connell v. Sears, Roebuck & Co., 722 F.2d 1542, 220 USPQ 193 (Fed. Cir. 1983)) 

3 Kalman v. Kimberly-Clark Corp., 713 F.2d 760, 771-72, 218 USPQ 781, 789 (Fed Cir. 1983) 
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In the Office Action, it is correctly asserted on page 4 that, "Strassner does not disclose 
the one or more protocols." Claim 1, as amended, recites in part, "one or more of a plurality of 
client protocols including versions thereof." Amended claims 13, 19, 20, 55, 65, 73, 74, 75, 81, 
87, and 88 have similar language distinguished from Strassner. Therefore, Strassner does not 
disclose or anticipate the embodiments as presently claimed. For this reason, Applicants 
respectfully request withdrawal of the § 102 rejections. 



§ 103 Rejection of the Claims 

Claims 2-3, 6-12, 14, 16-18, 21-53, 55-58, 60-64, 66-78, 80, 82-86 were rejected under 
35 U.S.C. § 103(a) as being obvious over Strassner et al. (U.S. Publication No. 2004/0230681) in 
view of Cooper et al. (U.S. Publication No. 2004/0039942). 

Applicants respectfully submit that the Office Action did not make out a prima facie case 
of obviousness for at least the following reasons. Even if combined, the cited references fail to 
teach or suggest all of the claimed elements of Applicants' claimed embodiments. 

In examining claims under 35 U.S.C. § 103(a), it is necessary for the Examiner to 
establish a proper prima facie case of obviousness before rejecting a claim as required by the 
Board of Patent Appeals and Interferences (BPAI). Such a rejection cannot be made if there is no 
evidence or suggestion in a cited reference of a claimed configuration. Ex Parte Katoh et al., 
Appeal 20071460, Decided May 29, 2007. Further, it is improper to reject a claim when there is 
no suggestion to combine the teachings of the cited references, except from using the Applicants' 
invention as a template through hindsight reconstruction of the Applicants' claims. Ex Parte 
Crawford et al., Appeal 20062429, Decided May 30, 2007. Moreover, a patent composed of 
several elements is not proved obvious merely by demonstrating that each element was, 
independently, known in the prior art. KSR Int'l v. Teleflex Inc., 127 S. Ct. 1727 (2007). See also 
M.P.E.P. § 2142. "[Rejections on obviousness grounds cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness." (See In re Kahn, 441 F. 3d 977, 988 (CA Fed. 
2006) cited with approval in KSR Int'l v. Teleflex Inc., 127 S. Ct. 1727, 1740-41 (2007)). 

Moreover, the recent U.S. Supreme Court decision of KSR v. Teleflex provides a tripartite 
test to evaluate obviousness. "A rationale to support a conclusion that a claim would have been 
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obvious is that all the claimed elements were known in the prior art and one skilled in the art 
could have combined the elements as claimed by known methods with no change in their 
respective functions, and the combination would have yielded nothing more than predictable 
results to one of ordinary skill in the art." (See KSR International Co. v. Teleflex Inc., 127 S. Ct. 
1727, 82 U.S.P.Q.2d 1385 (2007)). Emphasis added.) 

The U.S. Supreme Court recently held that rigid and mandatory application of the 
"teaching-suggestion-motivation," or TSM, test is incompatible with its precedents. KSR Int'l 
Co. v. Teleflex Inc., 127 S.Ct. 1727, 1741 (2007). The Court did not, however, discard the TSM 
test completely; it noted that its precedents show that an invention "composed of several 
elements is not proved obvious merely by demonstrating that each of its elements was, 
independently, known in the prior art." Id. See also M.P.E.P. § 2142. The Court held that the 
TSM test must be applied flexibly, and take into account a number of factors "in order to 
determine whether there was an apparent reason to combine the known elements in the fashion 
claimed." Id. at 1740-41. Despite this flexibility, however, the Court stated that "it can be 
important to identify a reason that would have prompted a person of ordinary skill in the relevant 
field to combine the [prior art] elements in the way the claimed new invention does." Id. "To 
facilitate review, this analysis should be made explicit." Id. The obviousness rationale addressed 
in KSR was premised on combining elements known in the prior art. Id. at 1738-39. A parallel 
analysis applies, however, to a rejection premised on the obviousness of modifying a known 
composition to change its properties. The KSR Court noted that obviousness cannot be proven 
merely by showing that the elements of a claimed device were known in the prior art; it must be 
shown that those of ordinary skill in the art would have had some "apparent reason to combine 
the known elements in the fashion claimed." Id. at 1741. In the same way, when the prior art 
teaches away from the claimed solution as presented here, obviousness cannot be proven merely 
by showing that a known composition could have been modified by routine experimentation or 
solely on the expectation of success; it must be shown that those of ordinary skill in the art would 
have had some apparent reason to modify the known composition in a way that would result in 
the claimed composition. 
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As explained above, Strassner does not disclose the one or more protocols of the 

embodiments as presently claimed. In the Office Action, it is argued on page 2 that: 

Strassner discloses the configuration data having fields including {V,T,M,P,OS} 
that used for specific devices see Par. 0070 & Par. 0072 & Par. 0060. And further 
configuration takes into account the different version for mapping device specific 
configuration see Par. 0060. The configuration manager has the task of approving 
changes, installing changes and verifying changes see Par. 0052. Additionally, the 
configuration changes to be inherited from higher layers and translate rules and 
procedures to configure network resources see Par. 0055. 

These paragraphs of Strassner called out in the Office Action are set forth below. 

[0052] Workflow engine 218 is configured to monitor and to manage the flow 
of sequential steps of configuring one or more network resources during the 
provisioning of a service. In particular, workflow engine 218 first manages the 
construction of the configuration change and then controls the deployment of such 
a configuration to support a provisioned service. The construction of the 
configuration can, for example, include selecting a person or group of people that 
are qualified to perform a particular configuration change (e.g., a change to a 
configuration file). The deployment of the changed configuration can further 
require: approving the changes, installing the changes, and verifying the changes. 
Thus, one person may only have authorization to change a configuration for a 
network device, such as a router, and another person might only have 
authorization to approve and/or implement such as change. 

[0055] FIG. 3 is an exemplary information model of information model 220 of 
FIG. 2, and is represented as a set of layered information "sub-models" according 
to one embodiment of the present invention. Each layer of information model 300 
includes a set of objects that are common to that layer, where each layer 
represents a different level of abstraction. Further, each layer can be a way of 
organizing information such that the information serves a common ontological 
purpose. Moreover, each of the layers is related to each other using appropriate 
relationships (e.g., associations, aggregations, compositions, and other like 
relationships). As an example, entities associated with lower layers of information 
model 300 can "inherit" characteristics of entities defined in its higher layers. As 
such, different programming models of the same device (or device feature) can be 
integrated and/or correlated with each other. Hence, different features that are 
prone to change (relative to other features associated with a network) can be 
isolated from each other. This allows specific feature changes in a device model 
(e.g., software revisions, as they are generally prone to change) to be easily 
accommodated by the network policies and by the business processes (e.g., as 
defined by business rules), depending upon those feature changes. And it also 
enables features that are prone to change to be separately modeled. As such, 
exemplary information model 300 is configured to manage objects, policies, and 
business rules as a homogeneous model, and it provides facilities to translate 
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business rules and procedures of an organization to the policies that configure and 
control its network resources. 

[0060] As an example, these objects can include administrator-related 
representations (i.e., associated with administrator view 356) used to translate or 
to map to technology-specific implementations from the system level. Translation 
372 represents the translational relationship between objects of system view 354 
and objects associated with administrator view 356. As another example, these 
objects can include device-related representations (i.e., associated with device 
view 358) for mapping or translating a selected implementation into a form that is 
appropriate for a specific type of device. Translation 374 represents the 
translational relationship between objects of administrator view 356 and objects 
of device view 358. In addition, these objects can include instance-related 
representations (i.e. associated with instance view 360) to translate or to map that 
specific type of device to a configuration that takes into account the specific 
software versions, memory configuration, and other factors ancillary to the 
functionality of the device. Translation 376 represents the translational 
relationship between objects of device view 358 and objects of instance view 360. 

[0070] An exemplary knowledge model 240 of FIG. 2 according to one 
embodiment of the present invention is configured to include "knowledge" (also 
referred to as "configuration knowledge") about network devices that are used to 
provision services. Knowledge model 240 is configured to enable different 
aspects of a device (e.g., its physical composition and/or its logical capabilities) to 
be modeled and related to each other. For example, such knowledge information 
can indicate the number of available ports on one or more routers (as a physical 
capability) that can be used to provision a service as well as the protocols 
available (as a logical capability) running on the interfaces of the routers. With 
such knowledge information, services can be provisioned without negatively 
affecting other provisioned services that are using the same network devices 
because the information model makes explicit the different relationships and 
dependencies between a service, the set of devices supporting that service, and 
even resources (e.g., memory) within a device. According to at least one 
embodiment, this "knowledge" information includes: a vendor ("V") (e.g., Cisco, 
Juniper, etc.) which manufactured the device, a type ("T") of device (e.g., router, 
LAN switch, ATM switch, etc.), a model ("M") of the device (e.g., Cisco 7513, 
Cisco 7206, etc.), a product ("P") family (e.g., a line card that can fit into any 
device described by a unique vendor, type, and model), operating system ("OS") 
version (e.g., 12.1(5)T, etc.), or any other like information regarding a specific 
network resource, such as a network device. 

[0072] FIG. 6 illustrates how knowledge can be organized according to a 
specific embodiment of the present invention. This knowledge can be organized 
and identified as a "five-tuple," such as: {Vendor, Type of device, Product family, 
Model of device, Operating System}, or "{ V,T,P,M,OS}" 602. As shown, a five- 
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tuple 602 is identified along five different dimensions, where each one of the 
dimensions is one of the five-tuple { V,T,M,P,OS}. Therefore, any point in space 
600 can represent the intersection of these five dimensions, where each dimension 
of the tuple can relate the physical and logical information characterizing a 
device. The conceptual model shown in FIG. 6 can used to provide a mapping 604 
from the {V,T,M,P,OS} five-tuple 602 to knowledge information 606. 

As evident in these portions of Strassner cited in the Office Action, there is absolutely no 
disclosure or suggestion of anything related to a routing policy. There is a general mention of 
data modeling a router. There is a mention that a router can be associated with logical 
information. There is also mention that the logical information can include protocol information 
and service information (e.g., connectivity using a VPN). However, as understood by those of 
ordinary skill in the art, connectivity information is not the same as routing policy information. 
At best, connectivity information may convey a topology of network devices. But, no routing 
information can be inferred therefrom. Further, there is no disclosure or suggestion in Strassner 
of an abstraction layer of a routing policy as presently claimed. There is no disclosure or 
suggestion in Strassner of mapping a routing policy configuration to an intermediate layer as 
presently claimed. There is no disclosure or suggestion in Strassner of verifying pairings in a 
routing policy as presently claimed. Again, there is no teaching or suggestion in Strassner of any 
processing related to a routing policy as presently claimed. The Office Action offers no 
explanation of how Strassner can cover the processing related to a routing policy as presently 
claimed. The portions of Strassner cited in the Office Action and set forth above are clearly 
unrelated to the routing policy embodiments as presently claimed. 

As correctly noted in a prior Final Office Action, Strassner does not disclose the claimed 
policy repository to verify the intermediate layer against a set of verification rules for one or 
more client protocols including versions thereof (prior Final Office Action at pg. 3, para. 1). 
Moreover, Strassner does not disclose generating a configuration data abstraction layer of a 
routing policy, the configuration data abstraction layer to map a routing policy configuration to 
an intermediate layer comprising fields, operators and arguments. Strassner describes mapping 
from a system-oriented representation to four implementation-oriented representations 
interrelated by relationships (Strassner, para. 0059). Strassner performs these mappings to 
provision a service using an information model configured to represent a network resource of a 
network. However, Strassner does not disclose or suggest the generation of a data abstraction 



AMENDMENT AND RESPONSE UNDER 37 C.F.R § 1.111 Page 22 

Serial Number:10/816,138 Dkt: 1370.066US1 

Filing Date: April 1,2004 

Title: METHOD AND COMPILER FOR ROUTING POLICY 



layer of a routing policy as currently claimed. Further, Strassner does not disclose or suggest the 
mapping of a routing policy configuration to an intermediate layer comprising fields, operators 
and arguments. The various levels of abstraction described in Strassner and shown in Figure 3 of 
Strassner do not include a routing policy abstraction. Further, Strassner does not describe 
verifying the intermediate layer against a set of verification rules for one or more of a plurality of 
client protocols including versions thereof, or generating compiled policy transmission language 
for use by the one or more client protocols including versions thereof. Amended claims 1, 13, 19, 
20, 55, 65, 73, 74, 75, 81, 87, 88, and the claims dependent thereon have similar language 
distinguished from Strassner. As such, the Applicants submit that Strassner fails to render 
obvious the embodiments as presently claimed. 

Cooper describes a method and apparatus for generating an initial policy specification 
file. A level of abstraction over a policy language is used, simplifying creating the file based on 
gross character characteristics of a network at the IP level, such as policy domains, communities 
of hosts, subnets, and firewalls. However, Cooper does not disclose generating a configuration 
data abstraction layer of a routing policy, the configuration data abstraction layer to map a 
routing policy configuration to an intermediate layer comprising fields, operators and arguments. 
The abstractions described in Cooper do not include a routing policy abstraction as currently 
claimed. 

Cooper describes a system that takes as input a policy file that has been generated using a 
policy generator wizard or other means, and a file containing network packet dump data that has 
been collected from an observed network by a packet capture, or that has been processed by a 
protocol monitor processor (Cooper, para. 0089). Cooper also describes a policy monitoring 
component 100 that includes a database 104 for storing synthesized information of the packet 
dump's 115 conformance to the specified policy performed by the policy engine 102 (Cooper, 
para. 0090). Thus, Cooper describes a system that compares network packet dump data with a 
specified policy to determine conformance. However, Cooper does not disclose or suggest 
verifying an intermediate layer against a set of verification rules for one or more of a plurality of 
client protocols including versions thereof, the set of verification rules being associated with a 
client dynamic link library (DLL) for each of the client protocols. Cooper does not disclose or 
suggest generating a compiled policy transmission language for use by the one or more client 
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protocols including versions thereof. In other words, Cooper is checking observed network dump 
data against a specified policy. Cooper is not verifying an intermediate layer against a set of 
verification rules for one or more client protocols that is not based on observed network data. 

Claims 1-20 include the elements distinguished above with respect to Strassner and 
Cooper. Specifically, these non-obvious elements are recited in independent claims 1, 13, 19, and 
20 as amended herein. With respect to Claims 55-88, Strassner and Cooper do not teach or 
suggest the combination of elements recited therein. In particular, Strassner and Cooper do not 
teach or suggest generating libraries for attach points associated with one or more versions of 
one or more client protocols. As argued above, Strassner is related to provisioning services and 
not related to generating libraries for attach points associated with one or more versions of one or 
more client protocols. Similarly, as argued above, Cooper does not check statements of a routing 
policy against the capabilities of one or more of the attach points. Cooper checks observed 
network dump data against a specified policy. It would not have been obvious to one of ordinary 
skill in the art to combine these references in the manner suggested in the Office Action. Claims 
55-88 include one or more of these non-obvious elements distinguished herein with respect to 
Strassner and Cooper. Specifically, these non-obvious elements are recited in independent claims 
55, 65, 73, 74, 75, 81, 87, and 88 as presented herein. 

Thus, Strassner or Cooper, alone or in combination, do not render obvious claims 1, 4-20, 
55, and 58-88 as currently presented. 

Therefore, for the reasons set forth above, Applicants respectfully request withdrawal of 
the §103 rejections and respectfully request allowance of the pending claims. 
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CONCLUSION 

Applicant respectfully submits that the claims are in condition for allowance, and 
notification to that effect is earnestly requested. The Examiner is invited to telephone 
Applicant's representative at (408) 406-4855 to facilitate prosecution of this application. 

If necessary, please charge any additional fees or deficiencies, or credit any 
overpayments to Deposit Account No. 19-0743. 



Respectfully submitted. 
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